A routing scheme for content-based networks is described in the paper by A. Carzaniga, M. J. Rutherford, A. L. Wolf, A routing scheme for content-based networking, Department of Computer Science, University of Colorado, June 2003, the contents of which are herein incorporated by reference.
In traditional control plane protocols, such as routing protocols or signaling protocols, messages are typically encoded in a raw binary format. That is, a message is defined as a sequence of fields with pre-defined and fixed sizes. Locating a given field in the message is simply a matter of reading data from a fixed offset. The semantics of a field are known in advance to be either numeric (hexadecimal) data, string or an enumerated value.
An example of a prior-art routing protocol utilizing pre-defined fields with fixed sizes is OSPF Version 2, as defined by RFC 2328, “OSPF Version 2”, April 1998, The Internet Society. An example of a routing message from OSPF is shown in FIG. 1. In this encoding format, the example routing message 1 is made up of a number of pre-defined, fixed size fields. For example, the packet type 2 is determined by the second field, where a value of 1 indicates a hello packet. The size of a given field cannot grow without changing the version number 3, which affects backwards compatibility. Moreover, new fields cannot be added, since the hello message has a variable sized list of neighbors 4 (i.e. repeated neighbor fields) at the end of the message. The Packet length 5 is used to determine how many neighbor entries are present.
More recently defined protocols often make use of a more flexible encoding, known as Type-Length-Value (TLV). In these schemes, each message consists of a series of data elements, and each element contains a “type”(which identifies both the field and semantics of the data), a “size” specified in bytes (which allows more flexible parsing of a message, when the tag value is not known by the receiver), and a “value”(the actual data assigned being propagated by this element). FIG. 2 shows an example TLV encoding in the prior art. The type field 11 is 1 octet, and indicates the type of information being encoded. Other names for field 11 is tag or code. The length field 12 indicates the number of octets which appears in the value field 13. The length field 12 is one octet, and the value field 13 contains the number of octets indicated by the length field 12. An example of a routing protocol using TLV encoding is IS-IS, as defined by RFC 1142, “OSI IS-IS Intra-domain Routing Protocol”, February 1990, the Internet Society.
An example IS-IS routing message utilizing TLVs is shown in FIG. 3, as per RFC 1195, “Use of OSI IS-IS for Routing in TCP/IP and Dual Environments”, December 1990, the Internet Society. FIG. 3 shows an example routing message 15, which is a “Level 1 Partial Sequence Numbers PDU”. In this message, the header portion 16 utilizes fixed field definitions similar to the OSPF example of FIG. 1. Field 17 indicates the number of octets in the header portion 16. Field 18 indicates the number of octets in the entire PDU, and the lengh of the variable length fields 19 is determined by field 18 less field 17. The variable length fields 19 is a sequence of TLV-encoded entries, with each entry using the format shown in FIG. 2. This method has similar limitations in the header portion, since fixed fields are utilized. However, the message is extensible through the use of variable length fields 19, using TLV encodings. If the entire message had been encoded with TLVs, including the header portion, then the message would have even further flexibility as described above.
A fundamental requirement of all networking protocols is that they must be extensible. That is, all protocols evolve, and new fields are added to messages or the size of existing fields is changed. Protocols with fixed message formats typically include a “version” field, which is modified to indicate a change in the protocol specification. There is, of course, a problem with backwards compatibility, as software implemented for a previous version of the protocol can not interpret the new message format.
Protocols utilizing TLV encoding are somewhat better suited to dealing with this; as the message parsing code can be designed to ignore “types” that it doesn't understand (i.e. new message fields), and cope with “lengths” that it does not expect (although in many cases this coping is limited, for example, if a software module is designed to expect a 16 bit integer for some value, and instead receives a 32 bit value, it would be forced to truncate, likely introducing a protocol error).
A common interoperability problem introduced by fixed or TLV formatted messages is caused by the different “endian-ness” of various system architectures. Protocols are typically defined as being in “big-endian” format, meaning the most significant bits and bytes are sent first on the network. However, a sloppy implementation of a protocol on a “little-endian” system may lead to the opposite behavior. Often in this case, encoding problems are not detected until two systems of different endian-ness are tested.
Another side effect of both the fixed or TLV formatted messages, is the increased difficulty of debugging network problems. Network sniffers are a common debugging tool, but much of the value of the network sniffer is it is built in protocol parser; that is, its ability to convert from binary messages to human readable form.